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FIELD OF THE INVENTION 

+h,^H fnr Pfficientlv delivering content 

suited to delivery of web content. 

BACKGROUND OF THE INVENTION 

pre-programmed content as ,n the case ot ^^^.^^ 
raaio, in an eftort to p.viae the a«,^ to — P-oco,s for the 
Video, efficiently there has been an effort „g. Distribution 
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processing power. ^ffipipnt use of the bandwidth of a 

; for information on-demand (as oppobeu 

"'''"wliat is needed is a system and method that allows a sen,er to handle more 
— - actual hand^dth ot a connection hetween the se.. 

and the Internet. 

0 

BRIEF DESCRIPTION OF THE FIGURES 

3 coniunctton with the accompanying drawings in wh^h ,,,,ed 
" FIG. 1 is a schematic diagram of a computer network according P 

I -'T::: — o, we^ se^. sonware in.erre,at.nshlps acceding to a 

I ^'^'^^r rrr ^::::"c. . ..^^^ — to . ..^r.. 

^"tr:' «:t:ot a «ow .agram ot a process pertonned hy a weh se^er 

accordingto a preferred embodiment of the invention^ 

or 4B is a continuation of the flow diagram shown in FIG. 4A. 

nr5isarwdlagramofaprocesspe.om,edhvanetworKrouteraccord,ngto 

'"''tr:T:^:Z^^ -f a pa., according to a preferred 
embodiment of the invention. 
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„i* ,he understanding that the present d s losure s , ^ 

the severa: views of the drawmgs. ^ p^^,^,^^^ 

P,G. 1 is schematic diag.m "'^ J^"^ ^es a server 102 contntunicatively 

— ' : -t data iinK t04. The 

., coupled to a first network suD pan . ^^^^^^ ^ 

a flrst network sub-pan 106 can for example ,3da«e 

y T1 line. The se.er 102 prefe.«v conges - ^ ^ , , 

.edium 126 is p^vided for ioading — ^ ,3^^,, 3hown in the 

I ^'%...n^o.su.pa..eisco— 

& directional data link 108 to a networK -'^J^^^ J J „ to car^ 

P 123 is provided, or i^g — ^^^^ 

out processes descnbed with reference ^^^^ 

— — — r a^a .ks m, and 

a third network sub-part 118, tnrougn 
25 116 respectively. -14 is communicatively coupled to a first client 

The second -^"^^^^^^^^ ,30. The third network sub-part is 

30 Tserver 102, Tirst Cient computer 12. and -^^:::XZZ 
for example comprise IBM PC compatible computers. IBM PC comp 
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include a microprocessor, Random Access Memo^ (RAM), Basic Inpu. Output System 

fn Mlrv (BIOS-ROM) video driver card, network interface (e.g. an ethemet 
Read Only Memory (biub Kum;, viuc 

interface or a modem), removable memory media reader (e.g. CD-ROM dr«e) 
« coupled though a digital signal bus. The «rs. and second Cent cor^pute^ 
5 "122 are loaded with web client software such as the Netscape Nav,gator web 
browser manufactured by America Online of Dulles, Virginia. 

BG 1 is merely illustrative of a simplified ne.wori< topology. An actua ne^ori^ 
the present Invention will be useful may include a mu.plicty of netwod. 
routers numerous sub-networks, servers, and clients. 
.0 P G. 2 is a schematic of exemplary web server software 200 -rre^ 

according to a preferred embodiment of the invention. The web server software 20 
according 10 p . ,,„tocoi stack 202 The communication protocol stack, as 
includes a communication protocol stack ^u^. ono 
5 ■ . ^oc .,n HTTP server application 204 at the top of the stack 202. 

I ~ Of : prese. — n Is that the inven«on, — 

4 .0 one preferred embodiment, supports communication with a convenfonal HTTP 
ff :: :i«on 204. The present inven^on therefore . compat^e w«h .^ng 
HnP selr applications without having to change the software and/or operation o, 
jj convenuonal HTTP server app^ca^ons. ^_ 
The HTTP server application 204, as snown 

mav include software that runs on a network interface card that ,s mcluded ,n the server 
25 102 sr FlG 1). The network interface layer 210 includes a transm queue 
25 102 (see Fie. ) ^^^^^^ ^ ^^^^^ ,„ 

ZZ::::::^-^^'^- » web revests u„^ 
available to transmK the responses through the first network -b-par. 10 ■ « t « web 
server 102 recedes client requests at a high rate or « the responses are large s^e^ 
30 rZeue will increase in size, and responses to client requests will be delayed. The 
present invention reduces those delays. 
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A sewer response condenser module 212 includes a packet read/write module 
218 a packet comparator 216, and a packet merger 220, The packet read/wnte 
module 218 reads and wntes packets to the transmft queue through the transm,. queue 
management module 210A. The packet comparator 216 compares the o^-- 
or more packets to be transmined that are read by the packet read/wnte module 218. 
The packet merger 220 merges two or more packets that are determ,ned to have 
common content payload by the packet comparator 216 into a single packet 
operations will be described in greater detail below. 

The Single packet produced by the packet merger 220 is passed by the packe 
read/w-fte module 218 to the transmit queue management module 210A for placemen, 
on the transmit queue, and the packets that were merged are removcKl ^'o'"^^^^^ 
By combining multiple packets that have the same content into a s.ngle P-^'. * - 
o, the t^nsm. queue can be signfficanUy reduced, thereby reducng the delay n 
sending responses to web clients 122, and 124 and increasing the capacty o the 
server. The single packe. preferably includes 1) a common content payload of the 
packets that were merged, 2) a lis, of at least one destination address ,dent,^,ng the 
destina.ion(s) for ,he single packet, e.g., a list of addresses from the packets that we e 
merged and 3) addi«onal infomiation for each of the destinations that can be used to 
conl;, a packet of the type that the destinations are expecting. Preferably, th,s per 
destination additional informafion is TCP header infom,ation that -n be used o 
construct a packet that can be handled by an ordinary unmodffled web cl,e,it, an^^ 
TCP/IP stack. A preferred process by which these TCP/IP packets are generated w,li 
be described below in the description of FIG. 5. 

The software interrelationships shown in FIG. 2 are merely illustrative of one 
i possible arrangement that can be used in practicing ,he invention. The arrangement 
can be varied. Functionality can be combined in dWerent software classes, modules, 
or subroutines, in different ways. The distribution of Unctions among different software 
^dules is ,0 some extent affected by the choice of programming language, and 
depends on prevailing trends in the computer programming art. Numerous alternative 
software arrangements are possible without departing fmm the true spirit and scope of 
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FIG 3 is a block diagram of an exemplary network router 110 according to a 
preferred embodiment of the invention. The router 110 includes a first input/output ca«) 
302A and a second input/output card 302B that are coupled to a switching fabnc 312. 
,n general, the router 1 10 may include a different number of input/output cards; two are 
shown in FIG. 2 for purposes of illustration in this example. The switching fabnc 312 
can for example be implemented as shared memory. Other types of switching fal^nc 
312 are also known in the art. A controller 316 is communicatively coupled to the 
input/output cards 302A, 302B, and switching fabric 312, and serves to control the 
overall operation of the network router 110. Although each input/output card 302A, 
302B can perfomi both input and output functions, the functions to be performed ,n 
carrying out the present Invention in the present example are performed when an 
input/output card receives a packet, i.e., when the input/output card is functioning as an 
input Accordingly the block diagrams of the input/output cards 302A, 302B, shown ,n 
FIG 3 highlight functional blocks involved in processing a received packet. The 
input/output cards 302A, 3028, can also Include other parts, as known to one of 
ordinary skill in the router art. 

Each input/output card 302A, 3028, includes a number of modules, as w,ll 
presently be described, that can be implemented as hardware, sofb«are or usmg a 
combination of hardware and software. (Alternatively, one or more of these modc^es 
could be implemented in the controller 316.) A packet parser/address analyzer 304A, 
3048 parses each packet to extract one or more addresses preferably more than one 
address, data, and optionally header data associated with each address. Address 
associater 306A, 3068, is communicatively coupled to the packet parser/address 
analyzer 304A, 304B, and to a forwarding table 310A, 310B. The fon«arding table 
; 310A 310B, can be implemented as a table stored in a memory on the inpuVoutput 
port ca«Js 302A, 3028. The forwarding table includes a plurality of records cons,st,ng 
of destination addresses, and corresponding next hop addresses. The address 
associater 306A, 306B, examines the one or more addresses parsed from a packet by 
the packet parser/address analyzer 304A, 3048, and associates together those 
0 addresses that are determined based on the forwarding table 310A, 3108, to have the 
same next hop address. New packet composers 310A, 3108, are communicatively 
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coupled to respective address associaters 306A, 306B, The r,ew packet composers 
310A 310B compose one or more packets each of which includes at least one 
address that has been determined to correspond to the same next hop address by the 

address associater. ♦ 
i Consider the following illustrative example. A packet, that includes 10 different 

addresses, can be received by input/output card 302A. These are parsed by the packet 
parser/address analyzer 304A. It may so happen that Ave of these addresses are 
detem,ined to correspond to a first next hop address, four to a second next hop 
address, and one to a thi^ next hop address. In this case the new packet composer 

0 308A will compose three new packets each of which includes the same data payload as 
the packet received by the input port card 302A. The first new packet will include the 
five addresses corresponding to the first next hop address, the second new packet w,^ 

1 include the four addresses corresponding to the second next hop address, and the th^rd 
i new packet will include the address corresponding to the thi«i next hop address. The 
is new packets preferably also contain addlBonal information that is parsed from the 
■1 received packet and associated with the various addresses. More preferably, the new 
" packets include TCP header infomiation for each address in the new packets. 

3 FIG 4A and FIG. 4B show a flow diagram of a process 400 perfomied by web 

server 1 02 (FIG. 1) according to a preferred embodiment of the present invention. In 

So process block 402 a first request for a web content item is received by the senrer 102 

3 from a first networked device (e.g., client 124). In process block 404 a request for the 
same web content item is received by the server 102 fix,m a second networt<ed device 
(e g client 122). The first and second requests preferably include network addresses 
to'be used in transmitting a requested item to the first and second networked device 

25 122 124 respectively. These network addresses correspond to the identity of the first 
and se«.nd networked devices 122, 124. More preferably the included network 
addresses are, respectively, addresses that identify the first and second networked 
devices 122, 124, as destinations of packets distributed in the network. 

The requests received in process blocks 402 and 404 preferably take the fomi of 
30 an HTTP request. The requests are preferably receded by the HTTP sender application 
204 (see FIG. 2) through the communication protocol stack 202. The HTTP server 
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H,„^ with a oreferred embodiment of the present invention, 
application 204, ,n accordance with a preferre 

oonventiona,. services the re^ue^^^^^^^^^^^ 

in response to the requests and ^^^'"^ by me 

protocol stack 202. The packets are destned for 

. . f.h»rpauests eq the first and second networked devices 1-;/, I ^ 

:r 0 U .ores packe. . - — 
----"^'-:l:~Cro: — , and avanab. 

" ^"^"^rrr.:rpr: — of .he prese. invention, the and 

. 3e J:11 are rLived, se.ced bv the 

i corresponding first and second packets cons.«ng — ^^^^J ^^d second 

i .quests, respec^velv, are stored ^^^J^ ^ ale interval that 

f tl^h the transmit queue, .ven 

:r::r ::ue :be «me th. .... zz 

;5o in the transmit queue. prepared in 

i: ,n process blocks 406 and 408 first and second packe s a p P 

30 request specific header. The first a ^ ^ „p ^^.g^er information. The TCP 
include reliable unicast header information. e.g.JCP header 
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Header information is used for connection .anagement purposes. * 
TCP header infom,a.ion preferably provides per des«na.ion tracing -^^8^ 
I tracing the flow of data to a parUcuiar destination such as the f,rst and second 
networked devices 122, 124, in the network. „,„„H oackets are 

Referring now to FIG. 4B, in process block 410 the f,rs. and second pa kets are 
aeten^ined to Lude in the pa,oad o, the packet the sa.e poriion o *e web .nte. 
i,e. P^cess biock 410 is preferably broken into a number of sub-steps^ V..«^ 
Tck 410 is preferably performed by a queue scan program module that reads packet 
a gue ( .9-. Ismi. gueue 210A). According . a preferred embodiment of 
e jsent invention, the queue scan p.gram module is preferably invo^d when 
packet is about to be added to the transmit gueue. This gueue scan prog m mod 

^^"^^ Tnte e^emplary embodiment, the gueue s<.n module «rst compares the 
payload size of a packet that Is about to be added to the gueue wKh the payload .z^o 

payload size it of course cannot have the same payload. 

The gueue scan module, according to a second exemplary e-bo -ent m 
compare a nom^alized or canonical checksum (described below) — 
Talad Of the packet to be added to the transmit gueue wrth that of packets alrea y on 
. be imit gueue. If the non^aiized checksum of the payload of the packet o be 
■ IZifferent from that o, a packet already on the gueue then i. can be concluded 
that the packet to be added has a different payload. 

T e gueue scan program module, according to a third exemplary embod,ment^ 
>5 may perfom, a byte-by-byte comparison between the pa^oad of the packet to be added 
Ztha, 0, each packet already in the transmit gueue. This byte-by-byte companson ,s 
verreliable way of determining a match between the payioads of packets^ However 
IL the most time and resource consuming functional sequence for de— 
Whether the pa^oad in the packet to be added to the transm,t ^^^ZT^l 
30 payload of one of the packets already in the transm,. gueue. Thereforo, a 
efficient approach is discussed below. 
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, another alternative embodiment, the byte-by-byte comparison may 
According to another altemativ ^^^^.^.^^ 
preterabiy be limited to iust those pacKet the r m ^^^^^^ 
„om,aiized checksums as discussed J"* found to have the same 

normalized checksums may be iim.ed to P-^«'^ ' reduces the overall 

5 payload size. The latter tiered operational sequence o sts r 
Lmputatlonalcostoftindingamatchbetweenthepa^^^^^^^^^^^^ 

that has been fom.ed in response to a request 
,0 communication protocol stack at which the queue s ma.nta.ned, 

.ecked against packets ^^'^2Z:2Z Z^^'^^-^- - 

1, the queue scan module checks the q ^ ^^^.^^ ^^^^^^^ 

IS .ha. is to be added to the queue, and when a ^ '° ^ 
,hen When the queue scan module .nds a — ^^^^ , „e 

;| queue further, because all other matchmg packets w,ll have 

!3 packet that was found. „„„ „f TCP header information, even if 

^n ^ TCP packet checksum varies as a fun<*on "^"^^ 

;= .he data carried by the TCP packet remains unchanged, or -^^^ ^ 

.hat are addressed .o two different — ^ ^ addresses 
I general have d«^n. - ^ in general be diffe.nt on 

are different an ~ ^ ^.^..um that covers the pa^oad but 

different connections. A ° 3„„ purposes by backing 

no. the TCP header Information can be obtained P 

out the variable header data, f-om a ^-<^^ ^^^^^^^ ^ ^„ ,,3ed 
- embodiment of the ^ 



variable data item: 
30 HC'=~{~HC + ~m + m") 
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where HC is a canonical checksum that does not depend on variable data; 
HC is a computed checksum that depends on variable header data; 

m i<; the variable header data; 

; predetermined value to be used in lieu ot the variable header data 

in computing the canonical checksum; and 

~ reoresents a ones complement operation. 
The foreX formula is presented in Re,ues. for Con,.ent (RFC) nun, e 
,e24 ^r^Xn 0. the internet Chec.su. via increment. Update, puhi.shea hy the 

'"'C^:r:r:r:L.op 

lock 414 the next hop address for the second packet is determined. In 
:ors::rsde.er.ned.hatthene_ 
„e. hop address tor the second pa^are the s^^.^^^^^^^^^^ ^ ^^^^^ 

— :rr sr - 0., one connexion to t. 

access* ' '^--j; ° ^ „e,<t hop addresses for each 

::: 4,:, :: :::: .ep : - - - hop addresses are the 

=^^^rr::::r:ta thi. pack, is composed that incudes, acoordin. toa 

lest speci. headers, and 3, a content pa,oad t.t is the ^^^^^ 

second packets. ^^t Id ^^^^^^^^^^^ headers 

hPaders preferably compnses the first ana seou m 

7,2 124 respectively. Preferably, this TCP header information can t>e used to 
: thit can be handled by an ordinary unmodified web dlent and a 
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,„eue instead of storing the ,i.t and second pacKets. i. either o, the fl.t and second 
pacRets were already stored in the transit queue, then the particular packet ,s 
etved f.n, the queue. According to a preferred en.hodi.en. of the pr^. 
invention, the combined packet, i.e., the thi^ packet, comprises a rel.able ™it,cast 

packet for distributing in the networi(. 

,n process block 420. the third packet is transn,itted to the next hop address^ 
The next hop address, according to an exemplar embodiment, identifles the network 
™uter 110 in the network. Thus, the size of the queue is reduced by replacng m lt,^e 
packets by a single packet. Note that packets need not be consecutive to be 
combined. Note too that although two packets were combined into a single packet ,n 
Tabove example, it is possible for 3, 4, 5. or more packets to be combined to 
.educe the size of the queue. The process of combining packets can -t-e du n 
the entire pendency of the combination packet in the transmit queue until it ,s time to 
transmit the combination packet into the network. 

,n the above discussed example, packets were combined in the transmit queue 
of a network interface module. A main advantage of this embodiment is that no 
Changes are required in the HTTP se^er (or other server) application software. Note, 
,bat the process of combining responses to requests can also be done at other levels in 
the web sewer software 200 (e.g., in modules 208, 206, or 204 in FIG. 2). 

Note that in some Internet applications such as HTTP, a response to a single 
request can take the form of a plurality of response packets, each including d fferen 
parts of a request item (e.g., image file). Under certain condftions such as when the 
ata rate of a flrst TCP/IP connection differs from that of a second TCP/IP connection, 
some of the first few pairs of packets that are prepared in response to two request for 
3 he same item of information may not be matched up because the interval betwe^^ 
When they are prepared is longer than a queue wait period, yet for the samejw 
requests, subsequent packets may be matched up. In effect one connection catches 

up to the second. .^..^^.r iin 

FIG 5 is a flow diagram of process 500 performed by a networi. router 110 
0 according to a preferred embodiment of the present invention. In process block 510, a 
ht^ packet (e.g., the thi^ packet transmitted in process block 420, is received by the 
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router 110. The third packet, according to one preferred embodiment of the present 
invention, includes a data payload (e.g.. the portion of the web content item), a first 
address, a second address, a first request specific header (e.g.. TCP header) and a 
second request specific header (e.g., a second TCP header). Although, in the interest 
3 of clarity in illustrating the invention, the discussion here is in terms of a third packet 
having a first and second address, the third packet can include any number of 
addresses and corresponding request specific headers. 

In process block 512, according to this exemplary operational sequence, a next 
hop address is determined based on the first address, and in process block 514 a 

0 second next hop address is determined based on the second address. In process 
block 516, the first and second next hop addresses are compared. Process block 518 
is a decision block, the outcome of which depends on whether the first and second next 
hop addresses are equal. If so, then the process continues with process block 520. in 

1 which the third packet is fonvarded to the next hop address. (This assumes that the 
(5 third packet did not contain additional addresses that correspond to a different next 
J hop. If other such addresses were present, then another packet would need to be 

• generated based on the other addresses for transmission to the respective next hop 
^ addresses.) 

J If the first and second next hop addresses are not the same, then the process 

|0 continues with process block 522, in which a fourth packet including the first address. 

^ the first request specific header information and the data payload is composed. 
Following process block 522, in process block 524. a fifth packet including the second 
address, the second request specific header information, and the data is composed. In 
process block 526 the fourth packet is transmitted to the first next hop address, and in 

25 process block 528 the fifth packet is transmitted to the second next hop address. 

In the example discussed above there were two desfination addresses in the 
packet received by the router 110. If there were more than two addresses, the 
processing of the received packet would likely be as follows. The router would 
determine a next hop address for each of the destinations, and then partition the 
30 destinafions based on their next hops. The router 110 would send to each next hop a 
packet that contains the data payload from the original packet, the list of destinafions 
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that correspond to that next hop, and the request specific header information for those 
destinations. 

Based on the content of the fonwarding table 31 OA a determination can be made 
as to whether or not the next hop is the final destination. If the next hop is the final 
5 destination then the next hop address corresponding to the destination address will be 
the destination address itself. If a next hop addresses corresponds to a final 
destination, e.g.. a requesting network device, such as first client computer 124 or 
second client computer 122. then the packet to be sent to the destination is composed 
in a format suitable for receipt by the desfination. Preferably the packet is composed as 

0 a reliable unicast packet i.e.. a packet that includes information for a reliable unicast 
header, e.g.. a checksum, window size, and a sequence number used in a reliable 

1 connection, e.g.. a TCP connection. More preferably, the packet is composed as a 
3 normal TCP/IP HTTP packet expected by a web client application (e.g.. Netscape 
j Navigator running over a TCP/IP communication protocol stack.). That is to say that 
is any formatting used to encode multiple destinafion addresses and multiple TCP 
i headers in the packet would be removed. The resulting packet would include a single 

TCP header for the final destination. 
1 If the number of destinations for a next hop is one. even if the next hop address 

3 is not the destination address, according to the preferred embodiment, the packet is 
20 preferably composed in a format suitable for receipt by the final destination. 
^ Alternatively, the packet can be fonwarded without conversion. 

FIG. 6 is a schematic representafion of a packet 600 according to a preferred 
embodiment of the present invention. Packet 600 indicates an exemplary form for the 
third packet composed in process block 418. and received in process block 510. 
25 according to a preferred embodiment of the invention. Although the third packet was 
discussed above as including two addresses, the packet can include two or more 
addresses as shown in FIG. 6. The packet includes a link layer header 602 (e.g.. an 
Ethemet header) and an optional IP header 604. The optional IP header 604 is useful 
for tunneling the packet 600 through existing technology routers, that do not support the 
30 present invention, to a router 110 such as shown schematically in FIG. 3 that is capable 
of carrying out the process 500 illustrated in FIG. 5. A reliable multi-cast protocol 
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.eader 606 is followed by a plurality of pairs of des«na.ion iP addresses 608^ 60BB^ 

d e08C, and corresponding request spe* reliable unicas. .ea er — 
610A 610B and 610C, preferably including TCP header inforn,at,on. The packet, m 
TexZle, further includes a data pa,oad 612 that preferably includes a po,t,on of 

" nhTp—tion can be realized in hardware, sof^are, or a co.bina^ of 
Hardware and software. Any Kind of computer system - or other apparatus adapted fo 
c"out methods described herein - is suited. A typical combina.on o 
alare and software couid be a general purpose computer system with a compute 
^Zr^ that. When being loaded and executed, controls the computer system such 
that it carries out the methods described herein. 

T e present invention can also be embedded in a computer P™^- P'°^ 
^ich comprises al, the features enabling the implementation o, the methods de cnb 
*ein and which - when loaded in a computer system - is able to carry out these 
me r^^^^^ program means or computer program in the present conte. mea 
1 expression, in any language, code or notation, of a set of ins.ruct,ons inten ed to 

se a system having an information processing capabll«y to perform a part,a. 
ZL eL dlrec^y or after either or both of the following a) convers,on to another 
language code or, notation; and b) reproduction in a different matenal form. 
, Each computer system may include, inter alia, one or more compute, an a, 

leas, a compute readable medium allowing a computer to read data, ,nstruct,on. 
messages o message packets, and other computer readable lnforma.,on ^m the 
::: r readable medium. The computer readable medium may in.ude non.^ 
^pmorv such as ROM, Flash memory. Disk drive memory, CD-ROM, and other 
. Zirlge. --lly,acompu.ermediummayinclude 

storage such as RAM, buffers, cache memory, and network circuits. Furthermore, the 
IZrreadable medium may comprise computer readable lnfom,ation in a trans,tor^ 
Tate medium such as a networi. link and/or a networi< interface, induding a w,red 
"r a wireless network, that allow a computer to read such computer readable 



30 information. 
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Wlhough speciflc embodiments of »e invention have been disclosed, those 
having ordinary skill in the art will understand that changes can be made to the specific 
embodiments without departing from the spirit and scope of the invention. The scope 
of the invention is not to be restricted, therefore, to the specific embodiments, and ,t ,s 
intended that the appended claims cover any and all such applications, modifications, 
and embodiments vi-ithin the scope of the present invention. 

What is claimed is; 
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